This chapter provides information about working with storage pools, including creating storage pools out of storage units, maintaining storage pools, and adding storage pools into a high-availability configuration.
The storage command node displays all the storage pools that are located on a SpinServer. Storage pools comprise one or more storage units. The primary purposes of storage pools are as follows:
To provide a logical block address space that is larger than is possible with a single RAID set
To provide a secure and robust log-recovery mechanism
To serve as a container for virtual file systems
The ranges and limitations for storage pools are as follows:
The minimum number of storage units per storage pool is 1. The maximum number of storage units per storage pool is 128.
The minimum number of storage pools per SpinServer is 1. The maximum number of storage pools per SpinServer is 16.
Storage pools can be expanded, but not reduced. To reduce the size of a storage pool, you must delete it and recreate it.
Sizes are listed in 1-MB (1,048,576-byte) blocks.
The device IDs for storage pools and storage units must be unique within a cluster.
With the optional SpinHA software, storage pools can also be set up in a high-availability (HA) configuration. An HA configuration requires at least two SpinServers in a cluster to provide service to storage pools.
In the SpinServer model, data is stored on logical devices called storage pools. Each storage pool is backed by one or more storage units. A storage unit is the abstraction of the physical storage (RAID sets and JBOD disks) that is attached to the SpinServer cluster.
You can use two or more SpinServers and the optional SpinHA software to set up a high-availability (HA) system that has no single point of failure. HA systems are used to provide storage to applications that require the utmost in availability, such as high-volume databases. In an HA system, two or more SpinServers share responsibility for a particular storage pool. If one SpinServer fails, the other automatically takes control of its disks and continues without losing any committed data.
The HA configuration guards against a SpinServer failure but not against a catastrophic failure of multiple disks (a failure that is beyond the ability of the RAID subsystem to contain). Because RAID sets are highly reliable, the HA configuration is a preferred solution for many storage administrators.
In a high-availability system, one SpinServer acts as the primary and another SpinServer acts as the active secondary. If additional SpinServers are available in the same cluster, they can be designated as passive secondaries. The roles of these different machines are as follows:
Primary—The primary machine receives client requests and propagates them to both the storage pool and, over a failover stream, to the active secondary.
Active secondary—The active secondary holds the failover stream from the primary until the data it holds is written to disk. If the primary stops sending the failover stream, or if the storage pool indicates that it has stopped receiving data from the primary, the active secondary writes the uncommitted data from the failover stream to the storage pool and takes over as primary. It then looks for a passive secondary that it can promote to active secondary.
Passive secondary—The passive secondary does not receive the failover stream from the primary. If either the primary or the active secondary fails, the passive secondary is promoted to active secondary. A passive secondary is promoted to active secondary on the basis of its priority. For instance, if there are three passive secondaries with priorities of 1, 2, and 3, the passive secondary with priority 1 is the first to be promoted to active secondary, followed by the passive secondaries with priorities 2 and 3.
To illustrate a simple HA configuration, assume that you have three SpinServers named A, B, and C. Server A is the primary, Server B is the active secondary, and Server C is the passive secondary. The following scenarios can occur:
If Server A fails, Server B takes over as primary and Server C takes over as active secondary.
If Server B fails, Server A continues as primary and Server C takes over as active secondary.
If Server C fails, Server A and Server B continue in their respective roles as primary and active secondary, and both servers look for additional servers that are designated as passive secondaries in case A or B fails. The search for a passive secondary happens only when A or B fails.
When a server in an HA configuration fails, its load is redistributed to other servers in the cluster. When designing an HA configuration, you must consider all possible failure scenarios and ensure that in a worst-case scenario of multiple server failures, the load on a single SpinServer does not exceed maximum capacities. An individual SpinServer has the following maximum capacities:
22 TB of total storage capacity
16 storage pools
Four (4) storage pools that the SpinServer serves as secondary (active secondary or passive secondary) in an HA configuration
For instance, you cannot have an HA configuration in which three 10-TB storage pools, each served by a primary SpinServer, are all configured to fail over to a fourth SpinServer. In the event that all three primary SpinServers failed in rapid succession, the 30 TB of total storage is beyond the capacity of the fourth SpinServer to absorb.
A single storage unit represents a single external RAID set that you have already created, or a single JBOD disk. One or more storage units can be used to create a single storage pool.
After creating storage pools, routine management tasks include the following:
Displaying all storage pools on a server
Deleting a storage pool
Displaying the list of storage units that comprise a storage pool
Designating a storage pool as high availability, and managing the HA attributes of the storage pool
Use the storage units commands to work with storage units. Use the storage pools commands to create storage pools and assign storage units to them.
The storage units show command provides a view of the external RAID sets or JBOD disk as seen from the Fibre Channel host bus adapters (HBAs). A single storage unit represents a single external RAID set that has already been created, or individual JBOD disks. Storage units are used in the creation of storage pools. A storage pool can be comprised of 1 to 128 storage units. The following ranges or limitations are defined:
Up to 1024 storage units (RAID sets or JBOD disks) per SpinServer.
Up to 127 storage units (RAID sets or JBOD disks) per Fibre Channel loop.
Up to 32 logical unit numbers (LUNs) per RAID array.
Use the storage units show command to display information about a storage unit. With no parameter, the storage units show command displays information about all storage units attached to a SpinServer. To display information about a single storage unit, use the command with the -deviceid parameter. The command displays the following information:
Device ID
World wide name
LUN
Fibre Channel device (FCD) ID
Primary host channel status
Primary host channel
Primary loop ID
Secondary host channel status
Secondary host channel
Secondary loop ID
RAID set ID
Type of disk chassis
Vendor
Product name
Revision number
Status (online, offline, or unused)
Damaged status (true or false)
Error (true or false)
Last error code (0 - 6)
Error description
Storage space size (in GB) on the storage unit
The command has the following syntax:
storage units show [-deviceid device_ID]
The following example displays information about a storage unit with the ID su0.
spinserver::> storage units show -deviceid su0 Device ID su0 World Wide Name 20000080e511632b LUN 0 FCD ID 0 Primary Host Channel Status connected Primary Host Channel 1 Primary Loop ID 133 Secondary Host Channel Status connected Secondary Host Channel 0 Secondary Loop ID 132 RAID Set r1s0 Type RAID 5 Vendor SPINNET Product 1316-06v2 Revision 5785 Status Online Damaged? false Error? false Last Error Code 0 Error Description success Size (GB) 136
To set the primary host channel and desired primary host channel for a storage unit, use the storage units modify command.
Possible values for the desired primary host channel include Auto, 0, 1, 2, and 3. If the value is specified as Auto, the SpinServer uses the primary channel that is selected by the Fibre Channel device; if the value is specified as 0, 1, 2, or 3, the SpinServer uses that value as the primary channel. The default value for a new storage unit is Auto.
The command has the following syntax:
storage units modify -deviceid device_ID -primaryhostchannel primary_host_channel -desiredphc {Auto | 0 | 1 | 2 | 3}
The following example sets the sets the storage unit named su0 to use primary host channel 1 and sets the desired primary host channel to Auto:
spinserver::> storage units modify -deviceid su0 -primaryhostchannel 1 -desiredphc Auto
A storage unit can be marked with an error in the event of a power failure or other system problem. You can determine whether a storage unit is marked with an error by using the storage units show command; error status is listed in the Error? column of the command's output. If a storage unit is marked with an error status, use the storage units clearerror command to clear the error status. The command has the following syntax:
storage units clearerror -deviceid device_ID
The following example clears the error status from a storage unit named su0:
spinserver::> storage units clearerror -deviceid su0
To create a storage pool, use the storage pools new command. Depending on the number of physical disks that are included in the RAID sets or JBOD disks that are being used, this command can take several minutes to complete. If the storage pool is to be part of an HA configuration, the SpinServer on which the command is issued becomes the primary SpinServer for the storage pool; the primary can be changed by using other storage pools commands. The command has the following syntax:
storage pools new -deviceid device_ID -layout {concatenation | stripe} -freespacealarm free_space_alarm_threshold -sunits [list_of_storage_units]
If you do not provide a value for the -deviceid parameter, a device name of the form poolnumber is automatically generated, where number is a sequential integer (for instance, 0, 1, 2, and so on). This is to ensure that new storage pools are given unique device IDs across the cluster.
The -sunits parameter is required. If a value is not specified for it, all unused storage units are used by default. If you are using the CLI and press the Tab key after the -sunits parameter, all unused storage units are automatically listed.
The following example creates a storage pool named sp1. The storage pool uses the stripe layout, has a free-space alarm threshold of 10%, and uses five storage units, numbered su0 through su4.
spinserver::> storage pools new -deviceid sp1 -layout stripe -freespacealarm 10 -sunits [su0,su1,su2,su3,su4]
To display configuration information about all storage pools or information about one storage pool, use the storage pools show command. To display information about a specific storage pool, use the command with the -deviceid parameter. To display configuration information about a list of all storage pools known to the SpinServer, use no parameter with the command. The command displays the following information:
Device ID (storage pool name)
UUID
Status (online, offline, busy, active, or passive)
Layout
Group size (in MB blocks)
Total storage pool size (in MB blocks)
MB blocks used
MB blocks available
Percentage of MB blocks used
Free-space alarm threshold (percentage)
Number of VFSs on the storage pool or pools
List of storage units that are known to the SpinServer
List of storage units that are required for the storage pool
Maximum number of active servers
Home server name
Primary server name
List of active secondary servers
List of passive secondary servers
Pool version
NVRAM version
Server priorities for failover
The syntax of the command follows.
storage pools show [-deviceid device_ID]
The following example displays information about a storage pool named sp0.
spinserver::> storage pools show -deviceid sp0 Device ID sp0 UUID 66b1714033b80b00336b6d696e370000 Status online Layout stripe Group Size (MB) 512 Size (MB) 138848 Used 20336 Avail 118512 Use% 14.6% Free Space Alarm Threshold (%) 1 # VFS 172 Storage Units Present su0 Storage Units Required su0 Max # Actives 1 Home Server Server1 Primary Server Server1 Active Servers Server2 Passive Servers Pool Version 17321 NVRAM Version 17321 Server Priorities Server2:1, Server1:64
To display the home SpinServer for one or more storage pools, use the storage pools show-home command. The command has the following syntax:
storage pools show-home [-deviceid device_ID]
The following example displays the home SpinServer of all storage pools.
spinserver::> storage pools show-home
Device Home Server Primary Server
ID
pool0 Server1 Server1
pool1 Server1 Server2
pool2 Server1 Server1
pool3 Server1 Server2
The home SpinServer for a storage pool is also listed in the output of the storage pools show and tools storage pools show commands, if the commands are issued with the -deviceid parameter to display information about a specified storage pool.
To display information about one or more storage pools as seen by a local SpinServer (that is, a SpinServer that is not necessarily the primary server for the storage pool or pools), use the storage pools show-local command. The command has the following syntax:
storage pools show-local [-deviceid device_ID]
The command displays the following information about the storage pool or pools:
Device ID (storage pool name)
UUID
Status (online, offline, busy, active, or passive)
The storage pools modify enables you to modify the free-space alarm threshold and the home SpinServer for a storage pool. You must run this command on the SpinServer that is the primary server for the storage pool. The command has the following syntax:
storage pools modify -deviceid device_ID [-freespacealarm free_space_alarm_threshold] [-homeserver home_spinserver]
The following example modifies a storage pool named sp1 such that the free-space alarm threshold is set to 5% and the home server is set to a SpinServer named Server0:
spinserver::> storage pools modify -deviceid sp1 -freespacealarm 5 -homeserver Server0
The storage pools setoffline command takes a storage pool offline. Only online or damaged storage pools can be taken offline. Using the command prohibits further access to the storage pool and takes all of the pool's VFSs offline. The storage pool remains offline across system restarts. The command has the following syntax:
storage pools setoffline -deviceid device_ID
Note: Only storage pools in the offline state can be disconnected or deleted. Run the storage pools setoffline command before using the storage pools disconnect command or the storage pools delete command.
The following example takes a storage pool named sp0 offline.
spinserver::> storage pools setoffline -deviceid sp0
The storage pools setonline command brings an offline storage pool back online. The argument of the -newprimary parameter specifies the SpinServer that the storage pool is to use as its primary server; by default, this is the storage pool's home server. The command has the following syntax:
storage pools setonline -deviceid device_ID -newprimary primary_server
The following example brings online a storage pool named sp0 on a primary SpinServer named Server1:
spinserver::> storage pools setonline -deviceid sp0 -newprimary Server1
Use the storage pools disconnect command to disconnect a storage pool from the SpinServer. Before using this command, run the storage pools setoffline command. The storage pools disconnect command disconnects a storage pool from the SpinServer. After the command is run, the SpinServer has no knowledge of the storage pool. If the SpinServer is restarted, the storage pool is again registered with the SpinServer. Do not use this command if you need to reuse a storage pool's storage units to create a new storage pool. For that purpose, use the storage pools delete command.
The syntax of the command follows.
storage pools disconnect -deviceid device_ID
The following example disconnects a storage pool named sp0.
spinserver::> storage pools disconnect -deviceid sp0
The storage pools delete command destroys the contents of the storage pool, freeing all the resources that the pool occupied. This is primarily useful for reusing the storage pool's storage units to create a new storage pool. To create a new storage pool after deleting the old one, use the storage pools new command.
Note: Only storage pools in the offline state can be deleted. Before deleting a storage pool, run the storage pools setoffline command.
The command has the following syntax:
storage pools delete -deviceid device_ID
The following example deletes a storage pool named sp0.
spinserver::> storage pools delete -deviceid sp0
To prevent the loss of data when shutting down a system, you must synchronize from the cache to the disk all the input and output (I/O) activities that are pending on a single storage pool. To accomplish this synchronization, use the storage pools sync command. The command has the following syntax:
storage pools sync -ssid spinserver -deviceid device_ID
The following example synchronizes all I/O activities that are pending on a storage pool named sp0.
spinserver::> storage pools sync -deviceid sp0
To expand the size of a storage pool, you must first determine whether you have sufficient storage disks, either RAID sets or JBOD disks, that are unused. With storage units available, use the storage pools grow command to increase the storage capacity of a storage pool by adding additional storage units (RAID sets or JBOD disks) to the storage pool.
Note: You cannot decrease the size of a storage pool.
The command has the following syntax:
storage pools grow -ssid spinserver -deviceid device_ID -sunits [list_of_storage_units]
The following example adds storage units named su0, su1, and su2 to a storage pool named sp0.
spinserver::> storage pools grow -deviceid sp0 -sunits [su0,su1,su2]
In the event of an error in the RAID subsystem, the storage pools need to be rediscovered to bring the pools back online. To force the discovery of the pools, use the storage pools forcediscovery command. After the command is run, the storage pools enter a busy state while a quick verification process is performed. After verification is complete, the pools are online and ready for normal VFS operations.
The command has the following syntax:
storage pools forcediscovery
The following example forces the discovery of all storage pools.
spinserver::> storage pools forcediscovery
To determine the current high-availability status of a storage pool, and to list a storage pool's primary, active secondary, and passive secondary servers, use the storage hastatus show command. Specify the -deviceid parameter to display information about a specific storage pool, or issue the command without the parameter to display information about all storage pools.
The command has the following syntax:
storage hastatus show [-deviceid device_ID]
The following example displays HA status for all storage pools in a cluster.
spinserver::> storage hastatus show
Pool Primary Server Active Servers Passive Servers
pool0 ServerA ServerB ServerC
pool1 ServerA ServerC ServerB
pool2 ServerC ServerB ServerA
Each secondary server for a storage pool must initially be added as a passive secondary. A passive-secondary server can then be promoted to active-secondary status. Use the storage pools addpassivesecondary command to add a passive secondary to a storage pool. Required information for the command includes the device ID of the storage pool, the name of the SpinServer, and the priority that the passive secondary is to hold. Possible values for the -priority parameter range from 1 (lowest priority) to 64 (highest priority). For instance, if an HA configuration includes a server named ServerA that has a priority of 2 and a server named ServerB that has a priority of 1, ServerA is promoted as an active secondary before ServerB if the primary or active secondary fails.
Note: If the number of active secondary servers for the storage pool is set to greater than zero, the first passive secondary server that was created is automatically promoted to active secondary.
Note: An individual SpinServer can serve as secondary to no more than four storage pools, whether as active secondary or passive secondary.
The syntax of the command follows.
storage pools addpassivesecondary -deviceid device_ID -passivesec spinserver -priority priority
The following example adds a SpinServer named NewServer as a passive secondary to a storage pool named sp0. The priority of the new server is set to 2.
spinserver::> storage pools addpassivesecondary -deviceid sp0 -passivesec NewServer -priority 2
You can set the priority for a passive secondary by using the storage pools setpriority command. The priority of a passive secondary determines the order in which it is promoted to an active secondary in the event that the primary fails. Priority values range from 1 to 64, with 64 being the highest; that is, a passive secondary set to priority 64 is the first to be selected as an active secondary, followed by a passive secondary set to priority 63, and so forth.
The syntax of the command follows.
storage pools setpriority -passivesec spinserver -priority priority
The following example sets the priority to 3 for a SpinServer named Server2.
spinserver::> storage pools setpriority -passivesec Server2 -priority 3
You can manually promote a passive secondary to active-secondary status. This is useful to increase the number of active secondaries for a storage pool, or to provide an extra measure of high availability before you manually fail over the current active secondary.
Note: If the number of active secondary servers for the storage pool is set to greater than zero, the first passive secondary server that was created is automatically promoted to active secondary.
Use the storage pools promotepassivesecondary command to promote a passive secondary. The syntax of the command follows.
storage pools promotepassivesecondary -deviceid device_ID -passivesec spinserver
The following example promotes a SpinServer named Server2 from passive secondary to active secondary for a storage pool named sp1.
spinserver::> storage pools promotepassivesecondary -deviceid sp1 -passivesec Server2
To change the arrangement of secondaries in an HA configuration, you possibly need to demote an active secondary to a passive secondary. Use the storage pools demoteactivesecondary command to demote an active secondary. The syntax of the command follows.
storage pools demoteactivesecondary -deviceid device_ID -secondary spinserver
The following example demotes a SpinServer named Server3 from active secondary to passive secondary for a storage pool named sp1.
spinserver::> storage pools demoteactivesecondary -deviceid sp1 -secondary Server3
To remove a secondary server from an HA configuration (for example, before taking the secondary server down for maintenance), use the storage pools removesecondary command. The syntax of the command follows.
storage pools removesecondary -deviceid device_ID -secondary spinserver
The following example removes a SpinServer named Server2 as a secondary for a storage pool named sp0.
spinserver::> storage pools removesecondary -deviceid sp0 -secondary Server2
To force a storage pool to fail over to an active secondary, use the storage pools failover command. The syntax of the command follows.
storage pools failover -deviceid device_ID -activesec spinserver
The following example forces a storage pool named sp0 to fail over to the active secondary named Server2.
spinserver::> storage pools failover -deviceid sp0 -activesec Server2
In a high-availability (HA) configuration, storage pools can fail over from one SpinServer to another. You can return one or more storage pools directly to their home SpinServers.
By default, a storage pool's home SpinServer is the SpinServer on which the storage pool was created.
The storage pools revertpools command returns all storage pools to their home SpinServers. The argument of the -deviceids parameter specifies the square-bracketed, comma-separated list of pools that are to be reverted. If you are using the CLI, press Tab after typing the parameter to get a complete list of storage pools.
The syntax of the command follows.
storage pools revertpools [list_of_pools]
The following example reverts storage pools pool0 and pool1 to their home SpinServers.
spinserver::> storage pools revertpools [pool0,pool1]
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.